Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Robustify yaw emergency estimator against GNSS glitches #23894

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

bresch
Copy link
Member

@bresch bresch commented Nov 5, 2024

Solved Problem

When a GNSS velocity glitch occurs, the likelihood of all the estimators go to 0, driving all the weights to 0 that triggers a reset of the estimator. This makes the estimator really vulnerable as it would immediately converge to the incorrect GNSS readings. Since the main EKF requires a valid yaw emergency estimate at this time to see if the sudden large velocity innovation can be due to an incorrect heading it could cause a false yaw emergency reset (to an incorrect value!).

Solution

  1. Use the compressed innovation (capped to 5 sigma) when calculating the likelihoods
  2. Simply limit the lower value of the weights but never trigger a reset

Tested in replay:
Screenshot from 2024-11-05 11-47-11

@bresch bresch added the EKF2 label Nov 5, 2024
@bresch bresch requested a review from haumarco November 5, 2024 11:27
@bresch bresch self-assigned this Nov 5, 2024
The likelyhood can be really small when the innovation is suddenly
large. This can occur during a GNSS velocity glitch and shouldn't reset
the filter as it would bring it back to a really vulnerable state.
@bresch bresch force-pushed the pr-ekf2_yaw_est_no_reset branch 2 times, most recently from 2a4d648 to fdb1248 Compare November 5, 2024 13:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: 👀 In review/test
Development

Successfully merging this pull request may close these issues.

1 participant